Emergent Information Pattern Driven Sensor Networks

ABSTRACT

Emergent information is created and utilized by an array of sensors. Each sensor is programmed with a trigger rule, which describes a local condition that must be met for the sensor to trigger an event signal, and a relationship rule, which describes a hierarchy of communication control among sensors in the array of sensors. When a predetermined percentage or weighting of the sensors trigger event signals, emergent information that describes conditions at the array location is generated.

The present invention is related to the subject matter of the followingcommonly assigned, copending U.S. patent applications: (1) Ser. No.11/______ (Docket No. END920070164US1) entitled “Water Friend or FoeSystem for Global Vessel Identification and Tracking”, filed ______,2007; (2) Ser. No. 11/______ (Docket No. END920070204US1) entitled“Emergent Information Database Management System”, filed ______, 2007;(3) Ser. No. 11/______ (Docket No. END920070205US1) entitled “PatternDriven Effectuator System”, filed ______, 2007; (4) Ser. No. 11/______(Docket No. END920070206US1) entitled “Anomaly Anti-Pattern”, filed______, 2007; and (5) Ser. No. 11/______ (Docket No. END920070318US1)entitled “Intelligence Driven Icons and Cursors”, filed ______, 2007.The content of the above-referenced applications is incorporated hereinby reference.

BACKGROUND OF THE INVENTION

1. Technical Field

The present disclosure relates to the field of sensor networks and thealerts they develop when sensing emergent information that they are cuedto look for.

2. Description of the Related Art

Currently, system sensors collect data in a non-intelligent manner. Thatis, even if a sensor has limited intelligence (e.g., a camera thatautomatically tracks moving objects), most of the data collected by thesensors, and then transmitted to a controller, is meaningless. That is,sensors typically transmit data in a continuous manner, such that mostof the transmitted data is “dead air” in which nothing of interest ishappening. Even if some intelligence is present in the sensor, the datatransmitted concerns what that particular sensor type is able to detect,and thus has little selectivity associated with such transmitted data.Thus, most sensors systems are either burdened with high positive andnegative error rates, or send “dead air,” or both. To find a subjectmatter of interest, the controller must perform extensive data mining,using programs that search for patterns of interest in the massiveamounts of previously stored data. Most searching is for simple, singlesensor type, threshold events.

SUMMARY OF THE INVENTION

Emergent information is first created. Patterns of such data, whichcomprise the emergent information, are then downloaded into and utilizedby an array of sensors. Each sensor is programmed with a trigger rule,which describes a local condition that must be met for the sensor totrigger an event signal, and a relationship rule, which describes ahierarchy of communication control among sensors in the array ofsensors. When a predetermined percentage (or weighting of importance) ofthe sensors trigger event signals, notices (or alerts) indicate thatsuch emergent information, which describes the pre-establishedconditions at the array location, has been generated.

The above, as well as additional purposes, features, and advantages ofthe present invention will become apparent in the following detailedwritten description.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are setforth in the appended claims. The invention itself, however, as well asa preferred mode of use, further purposes and advantages thereof, willbest be understood by reference to the following detailed description ofan illustrative embodiment when read in conjunction with theaccompanying drawings, where:

FIG. 1 depicts an exemplary array of sensors used to generate emergentinformation about a sensor field (sensor location);

FIG. 2 illustrates a downhole implementation of the array of sensors;

FIG. 3A is a flow-chart of exemplary steps taken to utilize emergentinformation that is created by an array of sensors;

FIG. 3B depicts a difference between process patterns and data patterns;

FIG. 4 illustrates an exemplary computer in which the present inventionmay be utilized;

FIGS. 5A-B are flow-charts showing steps taken to deploy softwarecapable of executing the steps described in FIGS. 1-3A; and

FIGS. 6A-B are flow-charts showing steps taken to execute the stepsshown in FIGS. 1-3A using an on-demand service provider.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Presently presented is a hardware, software and process system for usingemergent information patterns to drive a sensor network. As described indetail below, a field of smart sensors is interactive. A controllingsoftware, which describes a set of data representing search patterns forthe field of sensors, is pre-programmed or downloaded to the field ofsensors. Each sensor “votes” as to whether it has detected an externalstimulus that fits in any of the search patterns stored within thesensor. As the “vote” tally reaches a high enough percentage of“opt-in's,” against a time line per pattern, individual sensors withinthe sensor field take turns trying to get the results of the vote andits supporting details, already constantly shared amongst the sensorsusing a communications protocol, such as zigbee, which supports thesevoting and alternate sending techniques out via varioustelecommunications channels. Once one sensor gets the message out, theprocess re-commences.

Multiple information patterns can be searched for at once, since theinformation patterns are all pre-downloaded, and all can be checkedagainst all the time. These information patterns can be updated andchanged, and new information patterns can be added by a local or remotecontroller.

Reports generated by the output of data from the field of sensorsprovides pattern details (describing the pattern of sensed data),supporting data (that supports the pattern details), emergent results(next-level information that becomes “apparent” only after the data isreceived from the field of sensors), and other deterministic realtimeinformation (including diagnostic data regarding the health of eachsensor and its lines of communication with other sensors and thecontroller).

The novel system described herein is extremely valuable when attemptingto deal with deterministic realtime problems, including those resultingfrom circumstances that are more complex than those created by just asingle sensor being set off. Furthermore, the process and systemdescribed here are valuable to any situation where more than one sensoror type of sensor is needed to develop emergent information, or thatinformation needed for a human to recognize a pattern that serves auseful purpose.

This new system also creates a low power consumption profile for eachsensor, since each sensor does not have to report “no op” all the time(i.e., the present invention does not require each sensor to continuousreport insignificant non-events). As described herein, each sensor inthe field can take turns reporting that emergent information has beendetected for the whole field of sensors. This provides many networkpaths to get a report out when needed, since each individual sensor canbe connected separately (e.g., through a zigbee-type network) foroutbound purposes, and thus one sensor can report for all. This approachalso provides for deterministic realtime pattern evaluation, as well asconstant addition, deletion, and changes of information patterns to beanalyzed by the field of sensors. Furthermore, some of the field sensorscan be out and the overall field of sensors can still be successful dueto built-in redundancy. In addition, with some patterns, a tentative“yes” vote can automatically occur when a pre-determined level of “hits”by sensors (e.g., two-thirds of the sensors reporting against a pattern,or by weighting the value of individual sensor “hits”) is accumulatedwithin a time period, for example. Thus, a weighted percentage ofsensors hits will cause the “yes” vote to occur (such that each sensorhas a weighted value, and the weighted percentage is a product functionof the sum of the tripped sensors times each sensor's weighted value).

This system works by pre-establishing emergent information and itspatterns, and then downloading those patterns into smart sensors fieldsthat now analyze each sensor's external data capture to:

1) match against those patterns in deterministic realtime mode;

2) vote as to matches using inter-networking technologies within timelines per pattern;

3) signal out when a sufficient match is established;

4) monitor for sensor health;

5) accept constant downloads of adds, deletes and changes to searchpatterns; and

6) work in degraded conditions such as sensors out, overloadedcommunications, and interference.

With reference now to FIG. 1, an exemplary array of sensors 102 in anarray location 104 (sensor field) is depicted. For exemplary purposes,assume that the array location 104 is a coastline, in which there is ahigh traffic of maritime smuggling. The array of sensors 102 ispre-programmed with logic to detect suspicious activity. For example,the weather sensor 106 may detect inclement weather (e.g., cloud coverat night to make marine vessel detection difficult); the thermal sensor108 may detect a thermal image of a marine vessel (e.g., how manyengines it has and how many people are on board); a Closed CircuitTelevision (CCTV) camera 110 can intelligent detect and slave to movingobjects on the water; a radar 112 system can detect the speed andmovement of larger marine vessels; and an audio sensor 114 (e.g., anunderwater hydrophone, an air microphone, etc.) can detect and interpretcertain sound patterns for suspicious marine vessels (e.g., high-speed“cigarette” boats favored by drug traffickers). Within each sensor inthe array of sensors 102 is programmed trigger rules, relationshiprules, and emergent information logic.

A trigger rule is a rule that describes what conditions must be met fora sensor to issue an event signal to the other sensors in the array ofsensors 102. For example, weather sensor 106 may have a trigger rulethat requires weather sensor 106 to issue an event signal whenever alocal rain gauge, barometer and thermometer indicate rainy conditions.Similarly, thermal sensor 108 may have a trigger rule that requiresthermal sensor 108 to issue an event signal if the heat signature ofonly one person is registered in a cigarette boat, whose presence wasdetected by radar 112. The presence of the cigarette boat was put ontothe array of sensors 102 in response to a trigger rule (e.g., speed andpath measured by CCTV camera 110 and/or radar 112) being fired in radar112. Likewise, if audio sensor 114 recognizes an audio signature of asuspicious marine vessel (e.g., a cigarette boat), this causes thetrigger rule in the audio sensor 114 to cause the release of an eventsignal from the audio sensor 114.

Relationship rules are rules that define how sensors should commumicateamong themselves, and which sensor should communicate with a remotecontroller, if necessary. As shown in FIG. 1, all sensors areinterlocked, such that every sensor communicates with every other sensorin the array of sensors 102. However, in another embodiment, somesensors may communicate with only certain other sensors within the arrayof sensors 102, or some sensors may communicate with sensors in othersensor arrays (not shown).

The relationship rules also come into play if a consolidated eventsignal (based on a predetermined number of sensors in the array ofsensors 102 firing off event signals) is to be transmitted, via agateway 116 and a transmit network 118 (e.g., a local IP-based orsimilar network), to a remote controller 120.

Emergent information logic (either software or hardware) is also part ofeach sensor. That is, each sensor may be able to consolidate eventtriggers from all sensors in the array of sensors 102, in order togenerate emergent information that describes conditions about the arraylocation 104. Thus, in the example described above, each sensor may beable determine that, based on event triggers caused by stormy weather(signaled by weather sensor 106), an audio signature of a cigarette boat(from audio sensor 114), and fast movement of the cigarette boat from aknown drug-offloading location (from radar 112), a drug smugglingoperation is likely in effect. Response to this may be local (e.g.,turning on floodlights (not shown) in the array location 104) or remote(e.g., notifying a local law enforcement agency of the event).

As noted above, in a preferred embodiment, generation of emergentinformation is performed by the sensors themselves, thus being fasterand less prone to communication failures. However, in an alternateembodiment, event signals (responsive to trigger rules being met) may besent to a central controlling and emergent information patterngenerating server 120. This server 120 can display details of the eventsignals on a display 122, or a consolidation of the event signals can bedisplayed as emergent information on a display 124.

Referring now to FIG. 2, another exemplary use of the present inventionis presented. Assume now that the array of sensors comprises a pressuresensor 202 and a heat sensor 204 found in a downhole drill bit 206 thatis drilling a well 208 (not to scale). As teeth 210 cut throughdifferent soils and rock, they can be damaged. For example, assume thatteeth 210 are initially cutting through sand, but then hit hard rock. Toprevent damage to teeth 210, drill bit 206 needs to immediately slowdown, if not back away from the rock. If this pressure and heatinformation from pressure sensor 202 and heat sensor 210 were sent, viaan uphole communication uplink to a computer 214, the time required totraverse the communication cable 216 inside the drill string 218 may betoo long to avoid damage to the drill bit 206. Therefore, a localcontroller 220 causes the drill bit 206 to immediately alter operations(assuming that drill bit utilizes a locally controlled motor—not shown),thus preventing damage to the teeth 210 and the rest of the drill bitand motor. In a preferred embodiment, local controller 220 is not adifferent component, but is actually a compilation of rule and eventlogic (such as that describe above in FIG. 1) that is part of pressuresensor 202 and heat sensor 204.

Note that in one embodiment, computer 214 acts as a remote controllerthat is capable of updating the trigger rules and communication rulesfound in the sensors. That is, although pressure sensor 202 and heatsensor 204 comprise their own trigger rules (for triggering eventsignals) and relationship rules (for intra and extra-communication) tocreate the emergent information needed to stop the drilling operation,these rules may be downloaded and/or upgraded by computer 214.

With reference now to FIG. 3A, a flow-chart of exemplary steps taken toutilize emergent information from a sensor field is presented. Afterinitiator block 302, which may be prompted by a project to monitor fieldconditions, an array of sensors is deployed to an array location in thefield (block 304). These sensors are programmed (either before or afterdeployment) with trigger rules (block 306) and relationship rules (block308), which are described above. These rules may be pre-programmedbefore the sensors are deployed to the field, or they may be programmedby a remote controller as described above.

After the array of sensors are activated (block 310), a query is made todetermine if a predetermined percentage of the sensors have triggered anevent signal (query block 312). If so, this creates emergent informationthat describes an overall picture of conditions at the array location.Preferably, the array of sensors use their consolidated logic to performa local response (block 314), which addresses/corrects the perceivedconditions at the array location. Note that in one embodiment, thislocal response is to turn a sensor on. Thus, to conserve battery life, aparticular sensor may be turned on only if another sensor detects acondition in which the particular sensor is needed. In the exampledescribed above for drug interdiction (FIG. 1), the CCTV camera 110 maybe on “stand by” until radar 112 detects suspicious movement, thussaving power consumption by CCTV camera 110.

Alternatively, the consolidated response (emergent information) is sentto a remote responder (e.g., local law enforcement described in FIG. 1),as described in block 316. If a determination is made that a triggerrule or a relationship rule for one or more of the sensors needs to beupdated (query block 318), this action is performed by the remotecontroller (or alternatively, by one of the sensors). The process endsat terminator block 320.

Note that the present invention utilizes a data pattern approach, ratherthan a process pattern approach. That is, FIG. 3B demonstrates theprocess pattern approach (exemplified by thin lines 322) as the approachof collecting data 324, which leads to one or more observations 326,which leads to conclusions 328 and/or actions 330 that are controlled bya decision maker 332. The present invention bypasses most of these stepsby allowing data 324, which conforms to a known pattern, toautomatically lead directly to an action 330, as represented by a datapattern approach that is depicted by the thicker lines 334.

With reference now to FIG. 4, there is depicted a block diagram of anexemplary computer 402, in which the present invention may be utilized.Note that some or all of the exemplary architecture shown for computer402 may be utilized by software deploying server 450, as well as server120 and elements 106-116 shown in FIG. 1.

Computer 402 includes a processor unit 404 that is coupled to a systembus 406. A video adapter 408, which drives/supports a display 410, isalso coupled to system bus 406. System bus 406 is coupled via a busbridge 412 to an Input/Output (I/O) bus 414. An I/O interface 416 iscoupled to I/O bus 414. I/O interface 416 affords communication withvarious I/O devices, including a keyboard 418, a mouse 420, a CompactDisk—Read Only Memory (CD-ROM) drive 422, a GPS receiver 424 (e.g., GPSreceiver 206 shown in FIG. 2), and a SIM card drive 426 (e.g., SIM cardprogram 106 and/or SIM card reader 126 shown in FIG. 1). The format ofthe ports connected to I/O interface 416 may be any known to thoseskilled in the art of computer architecture, including but not limitedto Universal Serial Bus (USB) ports.

Computer 402 is able to communicate with a software deploying server 450via a network 428 using a network interface 430, which is coupled tosystem bus 406. Network 428 may be an external network such as theInternet or transit network 118 shown in FIG. 1, or an internal networksuch as an Ethernet or a Virtual Private Network (VPN).

A hard drive interface 432 is also coupled to system bus 406. Hard driveinterface 432 interfaces with a hard drive 434. In a preferredembodiment, hard drive 434 populates a system memory 436, which is alsocoupled to system bus 406. System memory is defined as a lowest level ofvolatile memory in computer 402. This volatile memory includesadditional higher levels of volatile memory (not shown), including, butnot limited to, cache memory, registers and buffers. Data that populatessystem memory 436 includes computer 402's operating system (OS) 438 andapplication programs 444.

OS 438 includes a shell 440, for providing transparent user access toresources such as application programs 444. Generally, shell 440 is aprogram that provides an interpreter and an interface between the userand the operating system. More specifically, shell 440 executes commandsthat are entered into a command line user interface or from a file.Thus, shell 440 (as it is called in UNIX®), also called a commandprocessor in Windows®, is generally the highest level of the operatingsystem software hierarchy and serves as a command interpreter. The shellprovides a system prompt, interprets commands entered by keyboard,mouse, or other user input media, and sends the interpreted command(s)to the appropriate lower levels of the operating system (e.g., a kernel442) for processing. Note that while shell 440 is a text-based,line-oriented user interface, the present invention will equally wellsupport other user interface modes, such as graphical, voice, gestural,etc.

As depicted, OS 438 also includes kernel 442, which includes lowerlevels of functionality for OS 438, including providing essentialservices required by other parts of OS 438 and application programs 444,including memory management, process and task management, diskmanagement, and mouse and keyboard management.

Application programs 444 include a browser 446. Browser 446 includesprogram modules and instructions enabling a World Wide Web (WWW) client(i.e., computer 402) to send and receive network messages to theInternet using HyperText Transfer Protocol (HTTP) messaging, thusenabling communication with software deploying server 450 and otherdescribed computer systems.

Application programs 444 in computer 402's system memory (as well assoftware deploying server 450's system memory) also include a SensorNetwork Manager (SNM) 448. SNM 448 includes code for implementing theprocesses described in FIGS. 1-3A. In one embodiment, computer 402 isable to download SNM 448 from software deploying server 450.

The hardware elements depicted in computer 402 are not intended to beexhaustive, but rather are representative to highlight essentialcomponents required by the present invention. For instance, computer 402may include alternate memory storage devices such as magnetic cassettes,Digital Versatile Disks (DVDs), Bernoulli cartridges, and the like.These and other variations are intended to be within the spirit andscope of the present invention.

Note further that, in a preferred embodiment of the present invention,software deploying server 450 performs all of the functions associatedwith the present invention (including execution of SNM 448), thusfreeing computer 402 from having to use its own internal computingresources to execute SNM 448.

It should be understood that at least some aspects of the presentinvention may alternatively be implemented in a computer-readable mediumthat contains a program product. Programs defining functions of thepresent invention can be delivered to a data storage system or acomputer system via a variety of tangible signal-bearing media, whichinclude, without limitation, non-writable storage media (e.g., CD-ROM),writable storage media (e.g., hard disk drive, read/write CD ROM,optical media), as well as non-tangible communication media, such ascomputer and telephone networks including Ethernet, the Internet,wireless networks, and like network systems. It should be understood,therefore, that such signal-bearing media when carrying or encodingcomputer readable instructions that direct method functions in thepresent invention, represent alternative embodiments of the presentinvention. Further, it is understood that the present invention may beimplemented by a system having means in the form of hardware, software,or a combination of software and hardware as described herein or theirequivalent.

Software Deployment

As described above, in one embodiment, the processes described by thepresent invention, including the functions of SNM 448, are performed byservice provider server 450. Alternatively, SNM 448 and the methoddescribed herein, and in particular as shown and described in FIGS.1-3A, can be deployed as a process software from service provider server450 to computer 402. Still more particularly, process software for themethod so described may be deployed to service provider server 450 byanother service provider server (not shown).

Referring then to FIGS. 5A-B, step 500 begins the deployment of theprocess software. The first thing is to determine if there are anyprograms that will reside on a server or servers when the processsoftware is executed (query block 502). If this is the case, then theservers that will contain the executables are identified (block 504).The process software for the server or servers is transferred directlyto the servers' storage via File Transfer Protocol (FTP) or some otherprotocol or by copying though the use of a shared file system (block506). The process software is then installed on the servers (block 508).

Next, a determination is made on whether the process software is to bedeployed by having users access the process software on a server orservers (query block 510). If the users are to access the processsoftware on servers, then the server addresses that will store theprocess software are identified (block 512).

A determination is made if a proxy server is to be built (query block514) to store the process software. A proxy server is a server that sitsbetween a client application, such as a Web browser, and a real server.It intercepts all requests to the real server to see if it can fulfillthe requests itself. If not, it forwards the request to the real server.The two primary benefits of a proxy server are to improve performanceand to filter requests. If a proxy server is required, then the proxyserver is installed (block 516). The process software is sent to theservers either via a protocol such as FTP or it is copied directly fromthe source files to the server files via file sharing (block 518).Another embodiment would be to send a transaction to the servers thatcontained the process software and have the server process thetransaction, then receive and copy the process software to the server'sfile system. Once the process software is stored at the servers, theusers, via their computers, then access the process software on theservers and copy to their computers file systems (block 520). Anotherembodiment is to have the servers automatically copy the processsoftware to each client and then run the installation program for theprocess software at each computer. The user executes the program thatinstalls the process software on his computer (block 522) then exits theprocess (terminator block 524).

In query step 526, a determination is made whether the process softwareis to be deployed by sending the process software to users via e-mail.The set of users where the process software will be deployed areidentified together with the addresses of the user computers (block528). The process software is sent via e-mail to each of the users'computers (block 530). The users then receive the e-mail (block 532) andthen detach the process software from the e-mail to a directory on theircomputers (block 534). The user executes the program that installs theprocess software on his computer (block 522) then exits the process(terminator block 524).

Lastly a determination is made as to whether the process software willbe sent directly to user directories on their computers (query block536). If so, the user directories are identified (block 538). Theprocess software is transferred directly to the user's computerdirectory (block 540). This can be done in several ways such as but notlimited to sharing of the file system directories and then copying fromthe sender's file system to the recipient user's file system oralternatively using a transfer protocol such as File Transfer Protocol(FTP). The users access the directories on their client file systems inpreparation for installing the process software (block 542). The userexecutes the program that installs the process software on his computer(block 522) and then exits the process (terminator block 524).

VPN Deployment

The present software can be deployed to third parties as part of aservice wherein a third party VPN service is offered as a securedeployment vehicle or wherein a VPN is build on-demand as required for aspecific deployment.

A virtual private network (VPN) is any combination of technologies thatcan be used to secure a connection through an otherwise unsecured oruntrusted network. VPNs improve security and reduce operational costs.The VPN makes use of a public network, usually the Internet, to connectremote sites or users together. Instead of using a dedicated, real-worldconnection such as leased line, the VPN uses “virtual” connectionsrouted through the Internet from the company's private network to theremote site or employee. Access to the software via a VPN can beprovided as a service by specifically constructing the VPN for purposesof delivery or execution of the process software (i.e. the softwareresides elsewhere) wherein the lifetime of the VPN is limited to a givenperiod of time or a given number of deployments based on an amount paid.

The process software may be deployed, accessed and executed througheither a remote-access or a site-to-site VPN. When using theremote-access VPNs the process software is deployed, accessed andexecuted via the secure, encrypted connections between a company'sprivate network and remote users through a third-party service provider.The enterprise service provider (ESP) sets a network access server (NAS)and provides the remote users with desktop client software for theircomputers. The telecommuters can then dial a toll-free number or attachdirectly via a cable or DSL modem to reach the NAS and use their VPNclient software to access the corporate network and to access, downloadand execute the process software.

When using the site-to-site VPN, the process software is deployed,accessed and executed through the use of dedicated equipment andlarge-scale encryption that are used to connect a company's multiplefixed sites over a public network such as the Internet.

The process software is transported over the VPN via tunneling which isthe process of placing an entire packet within another packet andsending it over a network. The protocol of the outer packet isunderstood by the network and both points, called tunnel interfaces,where the packet enters and exits the network.

Software Integration

The process software which consists of code for implementing the processdescribed herein may be integrated into a client, server and networkenvironment by providing for the process software to coexist withapplications, operating systems and network operating systems softwareand then installing the process software on the clients and servers inthe environment where the process software will function.

The first step is to identify any software on the clients and servers,including the network operating system where the process software willbe deployed, that are required by the process software or that work inconjunction with the process software. This includes the networkoperating system that is software that enhances a basic operating systemby adding networking features.

Next, the software applications and version numbers will be identifiedand compared to the list of software applications and version numbersthat have been tested to work with the process software. Those softwareapplications that are missing or that do not match the correct versionwill be upgraded with the correct version numbers. Program instructionsthat pass parameters from the process software to the softwareapplications will be checked to ensure the parameter lists match theparameter lists required by the process software. Conversely parameterspassed by the software applications to the process software will bechecked to ensure the parameters match the parameters required by theprocess software. The client and server operating systems including thenetwork operating systems will be identified and compared to the list ofoperating systems, version numbers and network software that have beentested to work with the process software. Those operating systems,version numbers and network software that do not match the list oftested operating systems and version numbers will be upgraded on theclients and servers to the required level.

After ensuring that the software, where the process software is to bedeployed, is at the correct version level that has been tested to workwith the process software, the integration is completed by installingthe process software on the clients and servers.

On Demand

The process software is shared, simultaneously serving multiplecustomers in a flexible, automated fashion. It is standardized,requiring little customization and it is scalable, providing capacity ondemand in a pay-as-you-go model.

The process software can be stored on a shared file system accessiblefrom one or more servers. The process software is executed viatransactions that contain data and server processing requests that useCPU units on the accessed server. CPU units are units of time such asminutes, seconds, hours on the central processor of the server.Additionally the accessed server may make requests of other servers thatrequire CPU units. CPU units describe an example that represents but onemeasurement of use. Other measurements of use include but are notlimited to network bandwidth, memory utilization, storage utilization,packet transfers, complete transactions etc.

When multiple customers use the same process software application, theirtransactions are differentiated by the parameters included in thetransactions that identify the unique customer and the type of servicefor that customer. All of the CPU units and other measurements of usethat are used for the services for each customer are recorded. When thenumber of transactions to any one server reaches a number that begins toaffect the performance of that server, other servers are accessed toincrease the capacity and to share the workload. Likewise when othermeasurements of use such as network bandwidth, memory utilization,storage utilization, etc. approach a capacity so as to affectperformance, additional network bandwidth, memory utilization, storageetc. are added to share the workload.

The measurements of use used for each service and customer are sent to acollecting server that sums the measurements of use for each customerfor each service that was processed anywhere in the network of serversthat provide the shared execution of the process software. The summedmeasurements of use units are periodically multiplied by unit costs andthe resulting total process software application service costs arealternatively sent to the customer and/or indicated on a web siteaccessed by the customer which then remits payment to the serviceprovider.

In another embodiment, the service provider requests payment directlyfrom a customer account at a banking or financial institution.

In another embodiment, if the service provider is also a customer of thecustomer that uses the process software application, the payment owed tothe service provider is reconciled to the payment owed by the serviceprovider to minimize the transfer of payments.

With reference now to FIGS. 6 a-b, initiator block 602 begins the OnDemand process. A transaction is created than contains the uniquecustomer identification, the requested service type and any serviceparameters that further specify the type of service (block 604). Thetransaction is then sent to the main server (block 606). In an On Demandenvironment the main server can initially be the only server, then ascapacity is consumed other servers are added to the On Demandenvironment.

The server central processing unit (CPU) capacities in the On Demandenvironment are queried (block 608). The CPU requirement of thetransaction is estimated, then the server's available CPU capacity inthe On Demand environment are compared to the transaction CPUrequirement to see if there is sufficient CPU available capacity in anyserver to process the transaction (query block 610). If there is notsufficient server CPU available capacity, then additional server CPUcapacity is allocated to process the transaction (block 612). If therewas already sufficient available CPU capacity then the transaction issent to a selected server (block 614).

Before executing the transaction, a check is made of the remaining OnDemand environment to determine if the environment has sufficientavailable capacity for processing the transaction. This environmentcapacity consists of such things as but not limited to networkbandwidth, processor memory, storage etc. (block 616). If there is notsufficient available capacity, then capacity will be added to the OnDemand environment (block 618). Next the required software to processthe transaction is accessed, loaded into memory, then the transaction isexecuted (block 620).

The usage measurements are recorded (block 622). The utilizationmeasurements consist of the portions of those functions in the On Demandenvironment that are used to process the transaction. The usage of suchfunctions as, but not limited to, network bandwidth, processor memory,storage and CPU cycles are what is recorded. The usage measurements aresummed, multiplied by unit costs and then recorded as a charge to therequesting customer (block 624).

If the customer has requested that the On Demand costs be posted to aweb site (query block 626), then they are posted (block 628). If thecustomer has requested that the On Demand costs be sent via e-mail to acustomer address (query block 630), then these costs are sent to thecustomer (block 632). If the customer has requested that the On Demandcosts be paid directly from a customer account (query block 634), thenpayment is received directly from the customer account (block 636). TheOn Demand process is then exited at terminator block 638.

The present invention thus overcomes may deficiencies found in the priorart. These deficiencies included, but were not limited to, (a) thesensor, even if “smart,” does not create any leverage or act as anythingother than an event tripper. All analysis is performed in a centralservice, and (b) there are many single points of failure including, butnot limited to: if a sensor fails, if the communication channel to thesensor is down, or if the data mining programs are too slow or notsearching for the right combinations to match the latest variation ofactivity. If these sensors are used in law enforcement or militarysituations, for example, the people or objects of interest areconstantly changing behaviors to avoid detection. If used in medicine,small variations person to person can cause basic observations to beinadequate or even lead to wrong conclusions.

The present invention, however, overcomes these deficiencies in theprior art by providing a robust, local intelligent network that iscapable of autonomously detecting and correcting problems in the field,without waiting for direction from a remote controller logic. Asdescribed herein, this invention reverses trend of using sensors thatare fettered to a remote controller, and instead deploys pre-designedsystems focused on the search for patterns in fields of different typesof sensors based on pre-downloaded, likely combinations, of data points,or emergent information patterns. A point of departure for developingthese search patterns to be downloaded into the sensor fields includesthe patterns searched for after the data is all collected in today'sapproach. This is a sensor “grid” computing system, where the sensorsthemselves are smart, and interact with each other with a short-rangecommunications protocol such as zigbee. This constant intercommunicationbetween sensors provides each sensor with a chance to constantly “vote”as to whether they have a known pattern they need to report, and notedagainst several or more already downloaded patterns at once. There aremany new patterns of search possible. Periodic reporting of a “no op”retains the network's confidence that it is still operating.

This new approach also creates a low power consumption profile for eachsensor because they don't have to report “no op” all the time. Rather,each sensor in the field can take turns reporting for the whole field.This approach provides many network paths to get a report out whenneeded since each individual sensor, in a zigbee type network, can beconnected separately and report for all. This approach also provides fordeterministic realtime data processing, such that constant addition,deletion, and changes of patterns can be analyzed. Furthermore, some ofthe field sensors can be out (disabled, off-line, powered down,“asleep”) and the overall field can still be successful, since innumbers there is built-in redundancy, and with patterns, the system canprovide a tentative “yes” vote (for reporting an anomaly) with somepredetermined percentage (e.g. two-thirds) of the sensors reportinginformation that conformed to a pre-defined anomaly pattern.

Note that in one embodiment, management of the field sensors is handledby a Service Oriented Architecture (SOA) service, which provides for themanagement of these sensor types, such as building, storing, forwarddeploying, managing, and storing and analyzing the results from the dataand emergent information generated by these sensors. Furthermore, an SOAservice can build on the capabilities of a pattern-driven sensor networkand Emergent Information Database Management System (EIDBMS) describedin the above referenced related patent applications.

While the present invention has been particularly shown and describedwith reference to a preferred embodiment, it will be understood by thoseskilled in the art that various changes in form and detail may be madetherein without departing from the spirit and scope of the invention.For example, while the present description has been directed to apreferred embodiment in which custom software applications aredeveloped, the invention disclosed herein is equally applicable to thedevelopment and modification of application software. Furthermore, asused in the specification and the appended claims, the term “computer”or “system” or “computer system” or “computing device” includes any dataprocessing system including, but not limited to, personal computers,servers, workstations, network computers, main frame computers, routers,switches, Personal Digital Assistants (PDA's), telephones, and any othersystem capable of processing, transmitting, receiving, capturing and/orstoring data.

1. A system for utilizing emergent information from an array of sensors,the system comprising: an array of sensors deployed to an arraylocation, wherein each sensor in the array of sensors is programmed witha trigger rule that describes a local condition that must be met for thesensor to trigger an event signal, and wherein each sensor in the arrayof sensors is programmed with a relationship rule that describes ahierarchy of communication control among sensors in the array ofsensors, and wherein each sensor in the array of sensors comprisesmultiple different trigger rules to be used in a creation of differentemergent information, and wherein the relationship rule defines how eachsensor, in the array of sensors, communicates with other sensors in thearray of sensors, wherein, in response to conditions at the arraylocation causing a predetermined percentage of sensors, from the arrayof sensors, to trigger event signals, emergent information is generatedby the array of sensors about the array location, wherein the emergentinformation describes conditions at the array location, and wherein theemergent information exists only when the predetermined weightedpercentage of sensors trigger event signals; a local controller that iscomposed of only the array of sensors, and wherein the local controllerresponds to the emergent information by using a consolidation of triggerrules from the array of sensors; and a remote controller for updatingthe trigger rule and the relationship rule in each sensor in the arrayof sensors.
 2. A system for utilizing emergent information from an arrayof sensors, the system comprising: an array of sensors deployed to anarray location, wherein each sensor in the array of sensors isprogrammed with a trigger rule that describes a local condition thatmust be met for the sensor to trigger an event signal, and wherein eachsensor in the array of sensors is programmed with a relationship rulethat describes a hierarchy of communication control among sensors in thearray of sensors, wherein, in response to conditions at the arraylocation causing a predetermined percentage of sensors, from the arrayof sensors, to trigger event signals, emergent information is generatedby the array of sensors about the array location, wherein the emergentinformation describes conditions at the array location, and wherein theemergent information exists only when the predetermined weightedpercentage of sensors trigger event signals.
 3. The system of claim 2,further comprising: a local controller that is composed of only thesensors in the array of sensors, and wherein the local controllerresponds to the emergent information by using a consolidation of triggerrules from the array of sensors.
 4. The system of claim 2, furthercomprising: a remote controller for updating the trigger rule and therelationship rule in each sensor in the array of sensors.
 5. The systemof claim 2, wherein each sensor in the array of sensors comprisesmultiple different trigger rules to be used in a creation of differentemergent information.
 6. The system of claim 2, wherein the relationshiprule defines how each sensor, in the array of sensors, communicates withother sensors in the array of sensors.
 7. A computer-readable mediumembodying computer program code, the computer program code comprisinginstructions executable by the processor and configured for utilizingemergent information from an array of sensors by performing the stepsof: deploying an array of sensors to an array location; programming eachsensor in the array of sensors with a trigger rule, wherein the triggerrule describes a local condition that must be met for the sensor totrigger an event signal; programming each sensor in the array of sensorswith a relationship rule, wherein the relationship rule describes ahierarchy of communication control among sensors in the array ofsensors; activating the array of sensors; and in response to conditionsat the array location causing a predetermined percentage of sensors,from the array of sensors, to trigger event signals, generating emergentinformation about the array location, wherein the emergent informationdescribes conditions at the array location, and wherein the emergentinformation exists only when the predetermined weighted percentage ofsensors trigger event signals.
 8. The computer-readable medium of claim7, wherein the instructions are further configured for: updating, from aremote controller, the trigger rule and the relationship rule in eachsensor in the array of sensors.
 9. The computer readable medium of claim7, wherein the array location is on a water coastline, and wherein thearray of sensors comprises a weather sensor, a thermal sensor, a videocamera, a radar system, and an audio sensor.
 10. The computer readablemedium of claim 7, wherein the array location is a well, and wherein thearray of sensors comprises a pressure sensor and a heat sensor coupledto a downhole drill bit.
 11. The computer readable medium of claim 7,wherein the relationship rule defines how each sensor, in the array ofsensors, communicates with other sensors in the array of sensors. 12.The computer readable medium of claim 7, wherein the relationship ruledefines which sensor, in the array of sensors, communicates with aremote controller for the array of sensors.
 13. The computer-readablemedium of claim 7, wherein the computer-usable medium is a component ofa remote server, and wherein the computer executable instructions aredeployable to a local computer from the remote server.
 14. Thecomputer-readable medium of claim 7, wherein the computer executableinstructions are capable of being provided by a service provider to acustomer on an on-demand basis.